A composite story about a network audit that surfaced more than the audit was asked to find, and what we did about the gap between scope and reality.

The brief came from the IT manager of a shared workspace operator, about 350 desks across three London buildings, with around 80 client tenant companies on the floors. The network had grown organically over a decade. Three different IT managers had come and gone. The current one had been in post for six months and had inherited a topology diagram that, in his own words, “is more of a suggestion than a record.”

He asked for a security audit. What he wanted on paper was a clean inventory: every access point (AP, the WiFi unit on the wall or ceiling), every switch (the network box in the comms cupboard that wires everything together), every device connected to the corporate VLAN (virtual LAN, a way of slicing one physical network into separate logical ones), every device on the tenant VLANs. We told him up front that a “complete” audit of an environment like this was probably impossible. He laughed and said “I know, give me the best version of impossible you can.”

What looked like the scope

We scoped four weeks. Discovery sweep across all three buildings, port-by-port physical labelling of every switch (the port is the socket on the switch where a cable plugs in), AP inventory with location and ownership tagged, a client-device fingerprint pass across each VLAN, written report with prioritised findings.

Tooling was standard: network discovery scans on each VLAN, MAC address (the unique hardware identifier built into every network card) and DHCP (the system that hands out IP addresses to devices that connect to the network) correlation, controller dump from the UniFi infrastructure, physical walks of each comms cupboard, weekly sit-down with the IT manager. The wired estate was what we’d expected, sprawling, partially documented, three switch generations from three different installers. The interesting things showed up in the wireless and the unlabelled client devices.

What actually showed up

Three categories of finding dominated the report.

Rogue access points. Six APs across the estate that weren’t on the operator’s UniFi controller. Three were old units from a previous install, left on the ceiling, broadcasting on four-year-old firmware. The other three were more interesting: APs that client tenants had brought in themselves, plugged into the operator’s switch ports, and configured with their own SSIDs (the WiFi network name users see when they pick a network on their phone). A small Netgear unit in a corner office, a TP-Link mesh node on a windowsill, and a UniFi unit a tenant’s own IT contractor had installed without asking. From the operator’s perspective, all three were rogue. From the tenant’s perspective, they were just “our WiFi.”

Unlabelled clients. About 40 devices across the corporate VLAN that we couldn’t pin to a known owner. Most turned out to be benign: a PA’s old iPad still associated, printers configured by previous staff with no record of who owned them, a CCTV recorder plugged in by facilities in 2022 with no documentation. A handful were less benign: two tenant-owned laptops connected to the corporate network rather than the tenant guest network, one by accident, one by deliberate choice because “the corporate WiFi was faster.”

Clients going around policy. Some tenants were operating in ways that bypassed the operator’s rules. Two were paying for a smaller bandwidth tier than they were actually using, because they’d connected their own APs to switch ports they shouldn’t have been on. One tenant was using a port that had been disabled three years ago and then physically re-patched by somebody since. We couldn’t tell who, and neither could the IT manager. Two were running their own VLANs piggybacking off the operator’s switches through tags that hadn’t been removed when the previous occupant left.

None of it was malicious in the headline sense. There was no obvious data exfiltration (no signs of data being copied out to an attacker). But the operator’s network wasn’t operating the way the operator’s policy said it should, and the audit surfaced exactly how.

How we handled it

The honest first move was telling the IT manager the audit could not be “complete” in the way the brief had implied. A network with 350 desks, 80 tenants, ten years of layered installs, and physical access to switch cupboards by multiple parties isn’t auditable to the standard of a closed corporate environment. Anything we called “complete” today would be stale next month.

What we delivered instead was a “known state” report in three sections: what we found and verified (the labelled inventory, rogue APs, unlabelled clients, policy bypasses); what we found but couldn’t verify (port activity and MAC addresses we couldn’t tie to a definite source); and what we know we didn’t look at (cupboards in tenant-controlled suites, devices powered off during discovery, anything behind tenant-owned firewalls). We told the IT manager section three needed to be explicit in his report to leadership. The alternative, pretending the audit was complete, would create a worse problem the first time something went wrong in an area we hadn’t looked at.

Then we worked through the remediation. Old rogue APs got removed. Tenant-installed APs got a conversation: either move onto the operator’s WiFi, or formally provision an isolated VLAN on a dedicated port with appropriate billing. The re-patching got addressed with physical port locks on the switches and a sign-off process for any new patching. Unlabelled clients got triaged into known-and-acceptable, known-and-needs-removing, and unknown-and-investigate.

The “ongoing audit” recommendation became the central output. Not a one-off audit, but a recurring discipline: a quarterly walk of cupboards, a monthly controller-vs-physical reconciliation, and a clear process for tenant onboarding and offboarding that closed the door behind them.

What we’d do differently

The mistake, partly ours and partly inherent to the brief, was accepting “audit the network” as a complete deliverable. Networks of this kind aren’t audited; they’re managed. A point-in-time snapshot starts going stale the moment the report is signed. If we ran this brief again, we’d reframe the deliverable as “baseline plus operating model”: the audit creates the baseline, the operating model keeps it accurate.

The other thing we’d do differently is the tenant conversation. We left those to the IT manager. Six months in post, he didn’t have the institutional authority to have them cleanly with tenants who’d been there for years. Some stalled. Two months later we ended up running them alongside him, but by then the tenants had had time to dig in.

Practical lessons

A few things worth carrying into any network audit in a shared or fast-growing environment:

  • “Complete” is the wrong word. Frame the deliverable as known-state with explicit unknowns. Tell the truth about the gap.
  • Walk every cupboard, label every port. It sounds tedious. It’s the single most useful thing we did on this engagement.
  • The unlabelled clients pile is always larger than you expect. Plan for it, and budget the triage time at the start of the engagement.
  • Rogue APs are almost always there. Old installs left behind, tenant-installed units, sometimes a sales-engineer demo from years ago. Find them with a wireless survey, not just a controller dump.
  • Switch-port physical security matters. If tenants can re-patch ports themselves, the logical policy doesn’t matter; the physical layer overrides it.
  • The audit is the easy bit. The operating model is the work. Build the recurring discipline into the engagement, not after it.

Where Security Solutions sits

Network audits in shared, sprawling, partially-documented environments are some of the most useful work the Security Solutions practice does, and some of the most uncomfortable, because the findings are rarely what the brief asked for. We’ll run the audit, we’ll build the baseline, and we’ll stay in the relationship to keep the baseline accurate, because that ongoing relationship is where the real value sits.

If your topology diagram is “more of a suggestion than a record,” that gap is already costing you. The next incident will land in an area the diagram doesn’t cover, and the recovery cost will be a multiple of what a baseline audit would have been.

If you’ve inherited a network you don’t quite trust and need somebody to help you draw a baseline, that’s our Security Solutions practice. Drop us a note at info@jmopartners.co.uk and we’ll set up a conversation.

JMO|Partners · Enterprise IT, sized for SMEs.