Office Network Audit: What to Inspect Before Upgrading

By Yogesh Sagale

Consider a hypothetical office where the complaint is familiar: “The network is slow, so we need faster internet and new Wi-Fi.” A quotation arrives, the equipment is replaced, and a month later the same complaint returns. The cause was never the internet circuit or the access points. It was an unmanaged switch daisy-chained behind another switch, a backup job saturating one link, and cabling that nobody had tested since it was installed.

An upgrade built on assumptions can spend money on the wrong layer. An audit is the evidence-gathering step that tells you which layer is actually limiting the office, which equipment genuinely needs replacing, and which problems a configuration change or a re-termination would fix. This article sets out what to inspect, in what order, what evidence to keep, and how to turn findings into an upgrade decision.

It is written for office owners, facility managers, IT administrators and project consultants. It is a practical audit framework, not a security assessment or a substitute for manufacturer documentation. Where the right limits depend on your equipment, the article says so.

What a network audit is, and what it is not

A network audit is a structured inspection of the network as it exists today. It answers four questions: what do we have, what condition is it in, how is it configured, and how does it perform under real use. It produces an inventory, a set of rated findings with evidence, and a recommended action list.

It is different from three things people often confuse it with:

• Troubleshooting chases one symptom. An audit looks at the whole network, including parts that are not yet failing.
• A penetration test actively attempts to break in. An audit reviews configuration and exposure without exploiting anything. Penetration testing is a separate, specialist engagement.
• A design proposes a future network. An audit documents the present one, so the design starts from facts.

For ongoing downtime problems, see our network downtime guide. This article is about the inspection you do before spending money on an upgrade.

Terms used in this guide

• Inventory: a record of every network device with make, model, serial number, firmware, location, role and support status.
• Baseline: measurements of normal behaviour (utilisation, latency, errors) taken over a representative period, used to judge whether a change helped.
• 95th percentile utilisation: the level that utilisation stays below for 95% of the measurement intervals. It is calculated from interval samples; a five-minute average can hide short congestion bursts. Retain peaks, drops and application timestamps as well, and state the sampling interval. It is not a pass/fail standard.
• CRC / FCS errors: frame errors counted on a switch port, commonly associated with bad cabling, bad connectors or duplex problems.
• Duplex mismatch: one end of a link operating half-duplex while the other is full-duplex, usually from a manual setting on one side or failed autonegotiation.
• Spanning tree (STP): the protocol that prevents switching loops. The root bridge is the switch all paths are calculated from.
• End of support / end of life: vendor lifecycle milestones are different. Record end of sale and last supported software/security-update dates separately; do not assume end of sale means support has already ended.
• Finding: a recorded observation with evidence, severity and a recommended action.

Step 0: Agree scope, permission and safety first

Before touching anything, settle the following in writing. NIST assessment guidance supports planned scope and methods; it does not make this practical capacity audit a penetration test. [5]

• Authorisation. Only audit networks you own or have written permission to assess. Active scanning and traffic capture on a network you do not control can breach policy or law.
• Scope. Which sites, floors, VLANs, devices and cloud services are included, and which are not.
• Access level. Prefer read-only accounts for devices. Avoid changing anything during the inspection phase.
• Timing. Agree when intrusive tests (throughput tests, scans) may run, and avoid business-critical hours.
• Backups. Save the current configuration of every managed device before the audit starts. If a device is already unstable, a backup may not be possible; record that as a finding.
• Privacy. Capture traffic metadata and counters rather than content. Do not retain personal data you do not need.

Step 1: Build the inventory and the real topology

An office may have an outdated network diagram, or none at all. Build the inventory from the devices themselves, not from memory or old invoices.

For every device, record:

• Make, model, serial number and role (firewall, core switch, access switch, access point, UPS).
• Physical location and the cabinet or rack position.
• Firmware or software version, and the vendor’s end-of-support status for that model.
• Management method (web, command line, cloud) and who holds the credentials.
• Licence or subscription expiry dates, and warranty status.
• Power source (which UPS or outlet).

Then draw the topology as it is physically connected. Trace uplinks between switches port by port. Pay particular attention to:

• Unmanaged switches hidden under desks, in meeting rooms or in ceiling spaces. They usually lack remotely accessible per-port counters. A neighbour may reveal their presence, but discovery cannot be assumed to inventory them completely.
• Daisy chains where one switch feeds another feeds another, which stack contention and failure risk on single links.
• Consumer routers acting as extra access points or switches, which may create a second network or a second NAT layer.

Discovery tools such as management consoles, neighbour discovery protocols and address-table views help, but they only find what is reachable and what supports them. Physical inspection of the cabinets is what catches the rest. If you run an active scan to find devices, do it only within the agreed scope and permission.

Step 2: Inspect the physical layer and cabling

Cabling faults produce some of the least visible and most persistent problems, and cabling is the layer most expensive to replace. Inspect before deciding anything about speeds.

Cabinet and patch area

• Cabinet temperature, ventilation and dust. Check measured conditions against the installed equipment’s operating limits; a closed cabinet alone does not prove a thermal fault.
• Cable strain, tight bends, over-tightened ties or cables hanging from connectors.
• Patch cord quality, length and condition. Damaged latches and cracked boots are common.
• Labelling: do the port labels in the cabinet match the outlet labels in the room, and do both match any documentation?
• Free ports, free rack units and free power outlets, which determine how easily you can grow.

Identify the installed cable

Upgrade options depend on what category of cable is actually in the walls. Check the jacket print on any accessible cable, the markings on outlets and panels, and any installation records. Printed markings are a clue, not proof; the cable and connectors together form the link, and only testing shows what the installed link can do.

Test a sample, or all links if the upgrade depends on it

If you intend to move to faster equipment, test the links against the standard for the application you intend to run. The difference between a continuity test and certification is covered in our Fluke testing article. For an audit, a practical approach is:

• Agree a sample that includes the longest runs, the oldest runs and links serving critical devices.
• Record the exact limit set, permanent-link or channel setup, adapters, tester model, calibration status and native result for each link. Agree requirements with the client and cabling manufacturer before testing. [3]
• If the sample shows a high failure rate, extend testing to all links before relying on the cabling for an upgrade.

A sample is evidence about the sample. It does not certify the links you did not test.

Step 3: Check switching health

For each managed switch, review the following. Command names and counter names are vendor-specific, so use the vendor’s documentation for your models.

Port status and errors

• Negotiated speed and duplex on every active port. A gigabit-capable pair negotiating at 100 Mbps needs investigation of cable pairs, patch leads, port settings and endpoint capability. CRC counters can indicate physical faults or interface problems; drops/discards may instead indicate congestion. Compare rising counters at both ends rather than declaring a cable failure from one number. [1]
• Error counters (CRC/FCS, input errors, discards). Note whether the counters are rising during the audit, not only their totals, because old counts may be historical.
• Ports flapping up and down, visible in logs.

Uplinks and utilisation

• Utilisation of every uplink over at least several working days, including backup windows. Record the 95th percentile and the maximum.
• Whether file servers, NAS devices or backup targets sit behind a constrained link.
• Link aggregation settings, if used, and whether members are correctly bundled and carry traffic over representative flows. Hashing can leave one member lightly used; equal utilisation is not required. A single flow ordinarily remains limited to one member link. [2]

Spanning tree and VLANs

• Which switch is the root bridge, and is that the switch you would choose? An old edge switch becoming root by default is a common finding.
• Frequent spanning tree topology changes in the logs, which suggest unstable links or loops.
• VLAN lists on trunk links: are the VLANs you expect carried everywhere they should be, and nowhere they should not?
• Unused ports: are they shut down or assigned to an isolated VLAN, or left open on the main network?

PoE

• Usable PoE budget versus reserved/negotiated allocation and current measured draw, per switch. The budget is a model-specific figure from the datasheet. The calculation method is covered in our PoE power budget guide.
• Any ports that have shut down or reset because of overload.

Firmware and management

• Firmware version against the vendor’s current release and security advisories for that model.
• Default or shared credentials, unencrypted management protocols, and management reachable from unauthorised guest or staff paths. Test the actual firewall/ACL policy; authorised administrator access should remain available.
• Time synchronisation and logging: do device clocks agree, and do logs go anywhere beyond the device itself?
• Whether current configuration backups exist outside the device and could actually be restored.

Step 4: Review the Wi-Fi network

Placement design is covered in our WiFi access point placement guide. An audit asks whether what is installed behaves well.

• Inventory: model, firmware, mounting location, uplink speed and PoE class of each access point.
• Channels and power: are neighbouring access points sharing channels? Record the band, width and regulatory domain, not only the channel number. Use the channels permitted for the installed equipment and location; same-channel APs share airtime, while overlapping channels can create additional interference. Check the actual radio conditions before changing a channel plan.
• Utilisation and retries: channel utilisation, client counts per access point and retry rates, taken during busy hours. High retries often point to interference or weak signal rather than too little bandwidth.
• Client mix: clients transmitting at low data rates consume more airtime for a given amount of data. Record their capabilities, signal conditions and traffic; an old client’s presence alone does not prove it is causing the complaint.
• SSIDs and security: how many SSIDs exist (each adds overhead), which security mode each uses, whether guest Wi-Fi is isolated, and whether any legacy or open network remains. For guest design, see our secure guest WiFi guide.
• Roaming and coverage: walk the floor with a survey tool or a test device and note dead spots, weak areas and sticky clients.

Do the walk-through in representative working conditions. Record channel utilisation, retries, signal/noise where available, client distribution and roaming symptoms; Cisco’s monitoring guidance supports examining these related measures rather than client count alone. [7] An empty office may miss the busy-hour load. Repeat both a wired and wireless local test before attributing poor service to the ISP.

Step 5: Examine the internet connection and the firewall

Internet circuit

• Contracted speed and whether it is committed or “up to”, for download and upload separately.
• Measured speed, latency, jitter and packet loss at several times of day, using a method you can repeat.
• Router or modem model and age, and whether the ISP equipment is in bridge mode or doing its own NAT in front of your firewall.
• Failover arrangements, if any, and whether they have ever been tested. See our dual ISP failover guide.

Firewall

Firewall hardening is covered in our business firewall setup guide. For an audit, review:

• Firmware version and vendor advisories for the model.
• Whether administration is reachable from the internet, and which accounts exist.
• Rule base: broad rules, unclear owners and stale entries. Confirm business purpose and logged use before removing them; a rule with no recent hits may still support a periodic business task.
• Port forwards and published services, and whether each is still needed.
• VPN configuration, user accounts and key or certificate expiry.
• Licence or subscription status for any inspection features, and verify the vendor’s actual expiry behaviour: signature updates, inspection services and support entitlement can behave differently by product.
• Logging and retention. Check what obligations apply to your organisation before deciding retention periods.
• Datasheet throughput under the enabled inspection features, versus measured demand and circuit speed. Check the vendor’s test conditions; laboratory ratings are not a guarantee for your applications. Record session load and CPU during the complaint before proposing a replacement.

Step 6: Check addressing, DHCP, DNS and segmentation

• Subnets and VLANs in use, and whether staff, guest, cameras and servers have suitable separation and permitted access paths. VLANs alone do not enforce security: verify routing, firewall/ACL rules and permitted/denied traffic.
• DHCP scope size versus active leases, and whether static addresses are excluded or properly reserved inside the dynamic range. A reservation is not the same as a conflicting manually assigned address.
• Duplicate addresses and unknown devices on the network.
• DNS servers handed out, and whether internal names resolve reliably.
• Whether any ranges overlap with VPN partners or remote sites, which makes later connection difficult.

Step 7: Check power and environment

• UPS model, battery age and last battery replacement. Use the selected-model status/self-test instructions first. A controlled discharge test requires an agreed outage/recovery window, recorded load and approval; document the limitation when it cannot safely be performed. Compare measured runtime with the business target.
• Total connected load against both the UPS watt and VA ratings. Compare runtime against the manufacturer curve at that load and battery condition. Do not double-count PoE endpoints already included in measured switch input watts. [6]
• Whether network equipment is on UPS-backed outlets, including the ISP equipment and PoE switches.
• Cabinet temperature and humidity, and whether the cooling or ventilation is adequate for the equipment.
• Earthing and power outlet condition, observed and recorded. Any electrical remedial work should be done by a qualified electrician under the applicable rules, not decided from this audit.

Step 8: Take baseline measurements

Without a baseline you cannot tell whether an upgrade helped. Measure over a representative period, including peak hours and backup windows:

• Uplink and WAN utilisation, with 95th percentile and maximum.
• Latency, jitter and packet loss to the gateway and to an external target.
• Port error counters and their rate of change.
• Wi-Fi channel utilisation, retry rate and client counts per access point.
• Throughput between key points, using a tool such as iperf3 between two hosts. This gives measured throughput under the test conditions, which is different from the nominal link speed and from what a user’s application will see.

Record the date, time, tool, settings and conditions with every measurement so the test can be repeated after changes. For iperf3, record client/server hardware, versions, direction, duration and stream count; restrict the test service to authorised hosts and stop it afterwards. Host CPU, NICs and the test path can constrain results. [4]

Step 9: Review operations and documentation

• Who administers the network, and is there a second person who can?
• Where are credentials stored, and are shared accounts in use?
• Is there a change log, and do configuration backups run automatically?
• Is there any monitoring or alerting, or does the office find out about failures from users?
• Are support contracts, licences and warranty terms recorded, with renewal dates?
• Does current documentation match what you found? The gap between the two is itself a finding.

Rating the findings

Rate each finding on likelihood and impact so the report separates urgent problems from housekeeping. Keep the scale simple and define it in the report.

Every finding should carry its evidence: a screenshot or export, a measurement with date and tool, or a photograph with location. Label an unsupported suspicion as an unverified hypothesis and record the evidence needed to confirm or reject it.

Worked example: a hypothetical 40-person office

Context: a 40-person office reports slow file access and dropped video calls. Management has asked for a quotation for faster internet and a full replacement of Wi-Fi.

Assumptions: three switches (24-port unmanaged, 24-port managed, 48-port managed), three access points, one firewall, one UPS, a 100 Mbps contracted internet line, and a chosen 80% review trigger for ports, uplink load, PoE and DHCP occupancy. These different measures are review prompts, not equivalent predictions of failure. The 71 occupied copper ports include uplinks and endpoint connections; they are not 71 user outlets. The measured PoE total includes phones and other devices not itemised here; device-level measurements and maximum/startup requirements remain necessary. Assume 12 of the /24’s 254 usable addresses are excluded for infrastructure, leaving 242 dynamic addresses. Leases include laptops, phones and visitors, not just 40 staff.

Findings log (hypothetical):

Decision: the audit does not support a blanket Wi-Fi replacement or a faster circuit as the first step. Findings 1, 2, 3, 4, 5, 6 and 7 are addressed by configuration, fault repair, power diagnosis and re-planning; unsupported or incapable equipment may still need replacement. A single overnight 820 Mbps peak does not by itself explain daytime video-call drops: correlate timings before linking the symptoms. After those are done and re-measured, the office can decide whether any equipment still limits performance. The delivered internet speed of 68 Mbps against 100 Mbps should first be repeated from a capable wired host with competing traffic accounted for, upload measured separately and firewall load checked. Escalate to the provider with evidence and the actual committed or best-effort contract terms; 68 Mbps alone does not prove an SLA breach.

Decision matrix: fix, replace or monitor

What the audit report should contain

• Scope, dates, methods and limitations, including what was not tested.
• The inventory and the as-found topology diagram.
• Baseline measurements with dates, tools and conditions.
• The findings log with severity, evidence and recommended action.
• A prioritised action list separating quick fixes from capital items.
• Open questions that need vendor or provider confirmation.
• The re-test plan, so remediation can be proven.

How audits go wrong

• Auditing only at quiet times, so busy-hour problems are missed.
• No baseline, so improvement cannot be shown.
• Trusting the old diagram instead of tracing cables.
• Missing unmanaged devices that never appear in a tool.
• Reading the speed on the box, rather than measured throughput.
• Treating a sample as a certification of all links.
• Changing things mid-audit, which contaminates the evidence.
• Findings without evidence, which cannot be defended to management or a vendor.

Using audit data to triage a “slow network” complaint

With a baseline and inventory in hand, a complaint can be narrowed quickly. Work from the bottom up and change one thing at a time.

1. Scope the symptom: one user, one area, one application, or everyone? Wired or Wi-Fi?
2. Check the physical link: speed and duplex negotiated, error counters, patch cord.
3. Check the access switch uplink against its baseline for the time of the complaint.
4. Check addressing: valid lease, correct VLAN, correct gateway and DNS.
5. Check Wi-Fi specifics if wireless: signal, channel utilisation, retries, clients on that access point.
6. Check the WAN against baseline latency, loss and utilisation.
7. Check the firewall for session counts, resource load and recent rule or firmware changes.
8. Compare with the change log for anything altered recently.

Acceptance: proving the audit and the fixes

Audit completion checklist

• Written scope and permission recorded
• Configuration backups taken before inspection
• Inventory complete, including unmanaged and consumer devices
• As-found topology drawn and verified
• Cabinet, patch and labelling inspection recorded with photographs
• Cabling sample tested and results stored
• Switch ports, errors, uplinks, spanning tree, VLANs and PoE reviewed
• Firmware and end-of-support status recorded for every device
• Wi-Fi survey and statistics captured during busy hours
• Internet circuit and firewall reviewed, including administration exposure
• DHCP, DNS and segmentation reviewed
• UPS model, load and battery age recorded; runtime/status checked under the approved method, or the untested limitation explicitly recorded
• Baseline measurements captured over a representative period
• Findings rated, evidenced and prioritised
• Report delivered with a re-test plan