An IT audit is often requested too late. The need appears when incidents multiply, when documentation is missing, or when a provider change becomes likely. At that stage the need already exists, but visibility remains weak.
The issue is not a lack of good intent. The issue is the lack of a shared reading base. Without a precise baseline, one quote appears comparable to another even though the perimeters are not. Without at least a minimum map of the environment, the most important risks stay buried in detail.
The real issue
In many SMBs, the word audit covers very different realities. Sometimes it means a hardware inventory. Sometimes a security review. Sometimes a quick pretext to price a takeover. That confusion greatly reduces the value of the work produced.
A useful audit before changing provider has a more precise function. It should make it possible to understand what exists, what is missing, what is fragile and what still depends on undocumented knowledge.
What an audit should make visible
The real perimeter
The first objective is to identify the assets and services that are actually in use. Endpoints, servers, Microsoft 365, backups, switches, firewall, Wi-Fi access points, printers, NAS, VPN, business applications, domains and cloud services should all appear inside the same logical inventory.
Critical dependencies
An IT environment often looks simple until the moment someone has to explain what stops when one component fails. One Internet connection, one domain controller, one NAS or one Microsoft 365 tenant can concentrate more dependencies than expected.
Documentation status
Lack of documentation is not only a comfort issue. It increases intervention time, weakens continuity and makes any recovery or quality improvement harder.
The real continuity level
A configured backup does not mean recovery is available. A stated DR plan does not mean a DR plan can actually be tested. The audit should distinguish what exists on paper from what has already been verified in conditions close to reality.
A useful checklist in six blocks
1. Inventory
| Check | Why it matters |
|---|---|
| List of endpoints and servers | Minimum basis for steering |
| Network equipment identified | Helps understand topology |
| Cloud services listed | Reduces invisible dependencies |
| Owners or referents named | Clarifies accountability |
An inventory that forgets cloud services or network components gives an incomplete picture. In SMBs, those omissions are common.
2. Access and identities
| Check | Risk signal |
|---|---|
| Known administrator accounts | Access held only by a third party |
| MFA enabled on sensitive accounts | Missing on Microsoft 365 or VPN |
| Shared accounts identified | Generic untracked accounts |
| Joiner and leaver process | Dormant accounts or excessive rights |
An external provider can handle daily operations correctly while leaving weak governance around access. That topic deserves its own reading.
3. Backups and recovery
| Check | Question to answer |
|---|---|
| Data actually backed up | What is covered and what is not |
| Known retention | How long data stays recoverable |
| Last restore test | Has recovery been proven |
| Backup location | Dependence on one site or one provider |
When the audit cannot answer those four questions clearly, the backup topic should move immediately to the top of priorities.
4. Network and connectivity
| Check | Main risk |
|---|---|
| Simplified topology available | Dependencies not understood |
| Segmentation present or absent | Network too flat |
| Firewall documented | Opaque or obsolete rules |
| Remote access identified | External access surface poorly controlled |
A very simple diagram is often enough.
Internet
|
Firewall
|
Core switch
/ | \
Users Servers Wi-Fi
That kind of view does not replace detailed configuration. It does make it easier to identify critical zones quickly.
5. Monitoring and operations
| Check | What it reveals |
|---|---|
| Active monitoring tools | Ability to detect early |
| Known patch policy | Real hygiene level |
| Existing reporting | Steering capability |
| Recurring incidents identified | Unresolved technical debt |
An environment may look stable only because it is barely observed. The audit should therefore distinguish real stability from lack of visibility.
6. Reversibility
| Check | Why it matters |
|---|---|
| Transferable documentation | Makes future change easier |
| Accounts and licenses under the right owner | Avoids dependency |
| Known third parties | Reduces handover time |
| Clear exit conditions | Secures the service relationship |
This block is often neglected when no immediate change is planned. It still remains one of the best indicators of environment maturity.
What should come out of the audit
A useful audit should not end with a simple raw list. It should at minimum produce three deliverables.
- A consolidated inventory.
- A prioritized risk list.
- An action plan split into short term, medium term and structural actions.
Without those three outputs, the audit describes. It does not help much with decisions.
Common mistakes
Confusing audit with a hardware catalog
A hardware inventory has value. It does not answer the questions of dependencies, continuity or sensitive access.
Trying to treat everything at the same level
Not every finding has the same weight. An outdated software version does not weigh the same as an untested backup or an unknown administrator account.
Launching a consultation without a baseline
Requesting proposals without a prior audit often produces quotes that are difficult to compare. Each provider then imagines a different perimeter.
What this changes in practice
A well-run audit reduces noise in the decision. It clarifies priorities, makes risks easier to read and strongly improves the quality of a takeover or a managed service contract.
It also helps distinguish a simple support need from a need for structured operations. That is exactly the point that separates one-off assistance from managed operations that are actually steered. In that logic, a provider such as Initial Infrastructures is more useful when taking over a perimeter that is already clarified than when it has to discover the environment under pressure.
Sources
- ANSSI Guide d'hygiene informatique
- NIST Cybersecurity Framework
- CIS Controls v8 Safeguards and Implementation Groups
Sources
Support available on this topic
Initial Infrastructures handles these topics for SMBs and mid-size companies. A short call is enough to identify priorities and the right scope of intervention.