IT Infrastructure Audit: What It Covers and What Turns Up in Week One

“Everything works here” is a sentence I hear often, and it is usually true, because things that stop working get noticed fast. An audit does not ask whether something works. It asks what happens when it breaks. Is there a backup, and has anyone restored from it? Is the server still supported? Is the account of the person who left in March still active?

An infrastructure audit answers those questions one by one, and writes the answers down.

What does an infrastructure audit look at?

Scope varies by company, but the headings are largely the same:

Area	What gets checked	Typical finding
Inventory	Devices, servers, licences, domains, certificates	An old device or subscription nobody owns
Backup	What is backed up, where, when it was last restored	Backups run but were never tested
Accounts and access	Admin accounts, leavers, shared passwords	Users with local admin rights
Network and firewall	Ports open to the internet, firmware, subscription status	Firmware untouched for years
Server and software lifecycle	Support end dates	A server OS past end of support
Endpoints	Patch level, disk encryption, protection software	Half up to date, half not
Email and cloud	Multi-factor sign-in, sharing settings, domain records	MFA off on legacy accounts
Process and ownership	Who runs what, who gets called when it breaks	Everything lives in one person’s head

Do not underestimate the last row. Half of the technical findings are really ownership findings. The device is old because nobody has the budget; the backup is untested because nobody has the job.

How long does it take and what does it need?

It depends on scope, but for a single-site office of twenty to thirty users, data collection usually takes a few working days and the write-up a few more. Multi-site setups take longer. What stretches the timeline is rarely technical difficulty; it is waiting for access, such as finding out who knows the admin password.

The auditor should get read-only access and change nothing. If settings are changed during an audit, that is no longer an audit but an intervention, and the two should stay separate.

Preparing these in advance speeds things up considerably:

• A device and server list, as complete as you can make it (gaps are fine; the gaps are themselves a finding)
• Admin sign-ins for the firewall, email, domain registrar and cloud services
• Licence and subscription invoices
• Backup jobs and the latest report
• Any documents left by a previous IT provider

How are findings ranked?

The value of an audit lies in the order of the findings, not the list. A fifty-item report moves nobody. I sort findings into three buckets:

1. Close this week. One-hour jobs with large risk: a remote desktop port open to the internet, a leaver’s active account, protection software that has been switched off.
2. Plan this quarter. A backup restore test, removing local admin rights, a replacement schedule for ageing devices.
3. Goes into the budget. A server past end of support, end-of-life network gear, restructuring licences.

The third bucket feeds your budget meeting. Windows Server 2016, for instance, reaches end of support on 12 January 2027, and Microsoft’s own page confirms that Exchange Server 2016 and 2019 support ended on 14 October 2025. If a server like that shows up in the inventory, the question stops being “should we replace it” and becomes “which month”.

Internal or external auditor?

The problem with auditing from the inside is that everyone sees their own work favourably. The person who set up the backup thinks it is adequate, because they built it to be adequate. An outsider has no problem asking why a server is still sitting there.

On the other hand, an outsider who does not understand the business gives everything equal weight. A report that treats the accounting server and a test machine alike is a report nobody reads. A good auditor starts with “which of these stops the business if it goes down”.

For a small company, an external audit every two years plus light internal checks in between is a reasonable balance. We covered the capability and spend side in our IT department audit article.

What should happen afterwards?

A report that goes into a drawer was money wasted. Every finding needs an owner and a date, plus a re-check date. Looking at the same list six months later and counting how many items closed is the real test of the audit.

For backups, the steps in our restore testing guide are a good start. For remote desktop, checking for an exposed RDP port takes five minutes.

Frequently asked questions

Do systems go down during an audit?

No. With read-only access users notice nothing. In rare cases that need intensive scanning, an out-of-hours slot is used.

Do we have to buy new equipment right after?

Usually not. Most findings are configuration, access and process fixes. Hardware and licence items go into the third bucket and are scheduled.

We don’t even have a device list. Can you still audit?

Yes, and producing that list is the first output. Devices on the network are scanned, cloud accounts are counted, and the result is compared with your records.

How often should it be repeated?

Before and after major changes (an office move, a provider switch, a merger), and otherwise about every two years. Backup and access checks are light enough to run quarterly.

If you would like an outside view of your infrastructure, you can write to us via the contact page.