What an infrastructure audit covers in its first two weeks

An infrastructure audit is only useful if it ends with a clear picture of what you run, what is at risk and what to fix first. This article walks through what a well-scoped audit covers in its first two weeks, in roughly the order the work happens, and what you should hold at the end of it.

Before day one: access and scope

The first days are lost if the auditor is waiting for credentials. Agree up front what is in scope (sites, data centres, cloud accounts, network edge, core servers) and what is explicitly out, such as end-user laptops or a legacy platform due for retirement.

Then arrange access that fits the work:

• Read-only accounts on network devices, hypervisors and cloud consoles, named per person and logged.
• Access to existing documentation, ticket history and monitoring dashboards, however incomplete.
• A named internal contact who can answer “why is it like this?” within a day.
• An agreed maintenance window for any test that touches production, such as a restore test.

Week one: inventory and network diagram

Building the inventory

The audit starts by establishing what actually exists, not what the spreadsheet says. That means pulling device lists from switches, routers, hypervisors, cloud accounts, DHCP and DNS, then reconciling them against the records you already have.

For each asset the inventory should capture role, location, owner, operating system or firmware version, support status and the services that depend on it. Devices nobody can explain are a finding in themselves.

Drawing the network as it is

A current network diagram follows from the inventory. A useful audit produces at least two views: a physical one (sites, racks, uplinks, carriers) and a logical one (VLANs, VRFs, subnets, routing domains, firewall zones and trust boundaries).

The diagram should show where traffic enters and leaves, which links are single points of failure and where IP address space is used. If you hold your own IPv4 or IPv6 resources, the audit should also check that registry records, route objects and ROAs match what is actually announced.

Week two: routing, firewalls, backups and monitoring

Routing and firewall review

On the routing side, the review covers BGP sessions and their filters, max-prefix limits, session authentication, RPKI route origin validation, internal routing design and how failover behaves in practice. Configurations are compared across similar devices to spot drift.

The firewall review looks at the rule base as a whole: overly broad permits, rules nobody can attribute to a service, shadowed or duplicated rules, missing IPv6 equivalents and management interfaces reachable from the internet. Each risky rule should be tied to an owner and a recommendation.

Backups and restore tests

A backup that has never been restored is an assumption, not a control. The audit checks what is backed up, how often, where copies are stored, whether at least one copy is offline or immutable, and how long retention runs.

Wherever possible it includes a real restore test of a representative system, timed from start to a working service. That measured time is far more useful for planning than a theoretical recovery target.

Monitoring gaps

The auditor maps what is monitored against the inventory. Typical gaps include devices with no monitoring at all, checks that confirm a host is up but not that its service works, alerts sent to a mailbox nobody reads, and no visibility of certificate expiry, disk growth or BGP session state.

Access, credentials and documentation

Access review runs alongside the technical work. It covers who holds administrative access, whether accounts are personal or shared, whether former staff and contractors still have working credentials, how secrets are stored, and whether multi-factor authentication protects consoles, domain registrars and registry accounts.

Pay particular attention to break-glass access. Someone should be able to recover the environment if the identity provider or the main administrator is unavailable, and that procedure should be written down and tested.

Documentation is assessed for usefulness, not volume. Can an engineer who has never seen the network find the runbook for a failed uplink, the contact for a carrier or the steps to restore the database? If the answer depends on one person’s memory, that is a risk to record.

What you should receive at the end

The output of the first two weeks should be concrete and usable without the auditor in the room:

1. An asset inventory, reconciled and exported in a format your team can maintain.
2. Physical and logical network diagrams that reflect the current state.
3. A findings report, with each issue rated by impact and likelihood and linked to evidence.
4. A prioritised remediation plan that separates quick fixes from projects needing budget or downtime.
5. Restore test results and a list of monitoring and documentation gaps.

A short debrief with your team matters as much as the report. It is where findings are challenged, missing context is added and priorities are agreed.

How TACS can help

TACS can scope and run an audit like this through its Consulting work, covering network, servers, cloud and IP resources in one engagement. If you then want the remediation and day-to-day monitoring handled for you, our Infrastructure management service can pick up directly from the findings report.