An infrastructure audit is often commissioned after an incident. That is the worst moment: the question becomes “why did this happen”, when the useful question is “what else can happen, and in what order”.
The first finding of an audit is almost never technical. It is documentary: nobody knows any more who holds a given access, what a given server is for, or whether a given backup has ever been restored.
Six areas, and the question that matters in each
The technical scope varies little from one company to another. What varies is the question you need to have answered.
- Network. Who can reach what? The addressing plan and segmentation say, by implication, what a compromised workstation could reach.
- Workstations and servers. Which versions are no longer supported, and which business function depends on each?
- Backups. When was the last restore attempted, and how long did it take?
- Access rights. How many accounts belong to people who have left? How many hold administrative rights with no current reason?
- Security. What actually happens the day a workstation is encrypted — who is told, how quickly, and by whom?
- Obsolescence. Which end-of-support dates fall within twenty-four months, and which of them takes a business project down with it?
None of these questions requires rare tooling. All of them require accepting the answer, including when it is “we do not know”.
What counting the accounts reveals
It is the most profitable exercise, and the simplest: list the accounts holding extended rights, then put a name against each. On an estate never audited, the proportion of accounts with no identifiable holder surprises every time.
It does not reflect negligence. It reflects ordinary accumulation — a provider who left, a project that stopped, a fix never closed out. The problem is not that they exist, it is that nobody knows they exist.
An account nobody knows about cannot be revoked, cannot be monitored, and is not counted in the risk.
The point where every audit looks the same
Thirty findings, a table, four colours. The document is complete and unusable: it leaves the director to arbitrate between anomalies he is in no position to compare.
A useful report ranks on two axes only: what it costs if it happens, and how likely it is. Three lines at the top — this is what we handle this quarter, this is what we schedule, this is what we accept leaving — are worth more than thirty equal ones.
What makes an audit useless
- It is carried out by whoever will sell the fix. The report then names the problems the provider knows how to handle.
- It assesses what exists without asking what it is for. An under-specified server for an abandoned use is not a risk.
- It does not say what it did not look at. An unstated scope reads as a covered scope.
The third point is the costliest. An audit that keeps quiet about its limits suggests full coverage, and the company files the subject away for two years.
When to commission one
Three situations justify it with no prior incident: before signing or renewing an outsourcing contract, before committing to a project that will build on what exists, and at the point where the long-standing technical contact is about to leave.
This survey says what you have. It does not say what threatens you first: for that you need to rank by scenario rather than by theoretical criticality.
In all three cases, what you are buying is not a technical diagnosis. It is knowing what you have before committing to something else.
Common questions
What is an IT infrastructure audit?
It is the review of six areas — network, workstations and servers, backups, access rights, security, obsolescence — to establish what could happen and in what order. Its first finding is often about documentation: what the business no longer knows about itself.
How do you check that a backup works?
By trying to restore it, and dating the attempt. A backup never restored is only an intention. The audit asks when restoration was last attempted and how long it took.
When should an infrastructure audit be done?
Ideally outside a crisis: before signing or renewing a managed-services contract, before a project that will rely on the existing system, or when the long-standing technical contact is about to leave. Ordered after an incident, it answers the wrong question.