An IT audit for a small business is a review of the information system — hardware, software, security, contracts, compliance — carried out by an outside eye, so that management can decide. The last part of that sentence is the one people forget. Many audits end with a complete, accurate and unusable report: a long list of findings, in no order, that nobody has time to turn into decisions.
A useful audit does the opposite. It ends with a small number of decisions, ranked by priority, each with its cost, its timescale and the risk it addresses. The rest of the report serves to justify that ranking.
When to launch an IT audit
An IT audit is not a periodic check done on principle. It answers a decision that has to be taken, and that decision sets its scope and level of detail. Four moments come up again and again:
- Before investing. New management software, a move to the cloud, a hardware refresh: knowing what exists avoids paying twice.
- Before changing supplier. Understand what the current supplier actually does, what it holds and what will have to be taken back.
- After an incident. An outage, a leak, an attempted intrusion: establish what failed, and what could fail next.
- When management or ownership changes. A new managing director, a sale, a funding round: someone asks for a reliable picture, and nobody is able to give it.
In each case, the question asked at the outset determines what is looked at first. An audit without a precise question looks at everything with the same attention, and that is how it ends up producing a report with no order.
It is also worth saying what an IT audit is not. It is not a certification, which attests compliance with a standard. It is not a penetration test, which technically tests a system’s resistance to attack. And it is not a legal opinion. It may recommend any of these when its findings call for it; it does not replace them.
The scope of an IT audit for a small business
The scope covers four areas. They are examined together, because the most serious risks often lie at the borders between them — a backup provided for in the contract but never tested, access granted to a supplier and never withdrawn.
Infrastructure and devices
Servers, network, workstations, phones, installed software: their condition, age, update level, and the date on which they will stop being maintained. This part draws on the asset inventory, where one exists — and building it is often the audit’s first result. That is the purpose of IT asset management, and the ground covered by an infrastructure audit when deeper work is needed.
Security and backups
Accounts and access rights, passwords and authentication, security updates, device protection, and above all backups: do they exist, are they kept separate from the system they protect, and has anyone ever checked that they can be restored? ANSSI’s IT hygiene guide provides a recognised reference for this part; it is better to measure against it than against an improvised list.
Contracts and suppliers
Who does what, under which contract, with what commitments, until when. This part almost always reveals surprises: services paid for but not delivered, response-time commitments never measured, missing reversibility clauses, access held by suppliers who have left. It also sheds light on dependence: could the business change supplier tomorrow without losing control of its system?
Compliance
Record of processing activities, GDPR processing contracts, data retention, informing employees about monitoring tools, and sector-specific obligations where they exist. The audit does not replace a legal analysis, but it establishes the facts that analysis will rely on: which processing exists, where the data is, and which suppliers have access to it.
Added to these four areas is a cross-cutting question that only interviews can address: how are the tools really used? Workarounds — the shared file outside the official tool, the online service signed up for by a team, the password shared by a whole department — appear in no document. Yet they show where the system fails to meet the need, and that is often where the most concrete risks lie.
How an information system audit runs
An audit of a small business’s information system runs in four stages. Their length varies with the size and complexity of the business; their order does not.
- Scoping. The question to answer, the scope, the people to talk to, the documents to gather. An hour well spent here saves ten later.
- Collection. Interviews with management, users and suppliers; reading contracts and invoices; technical readings on equipment and accounts.
- Analysis. Compare what is said, what is written and what is observed. The gaps between the three are the most useful findings.
- Presentation. Present the decisions to be taken to management, in order, and discuss them — not merely hand over a document.
The audited business has its share of the work. It gathers contracts, invoices and access to the admin consoles; it makes a few key people available for short interviews; and it informs its suppliers, who will be questioned. An audit that waits weeks for its documents costs more and concludes less well.
The question of who carries out the audit is not secondary. An auditor who will then sell the fixes does not have the same interest as one who will sell none: an IT audit is only worth the independence of whoever conducts it.
The deliverables to insist on
Four deliverables, no more. Their form matters less than their use: each must be usable by someone other than the auditor.
- An executive summary for management: the situation on one page, the main risks, and what needs deciding.
- A list of prioritised decisions, each with its estimated cost, timescale, the risk it addresses, and who should own it.
- A map of what exists: applications, equipment, suppliers, contracts, access rights — a document that stays useful after the audit.
- Detailed findings, as an appendix, to justify the ranking and to serve the technical teams.
The ranking rests on three questions asked of each finding: how serious would it be if the risk materialised, how likely is it to materialise, and what does fixing it cost? A serious, likely risk that is cheap to fix goes to the top; a theoretical risk whose fix would take a large budget waits for the multi-year plan. Writing down these three answers for each decision makes the ranking open to discussion — in the good sense: management can challenge it point by point.
The list of decisions is the heart of the deliverable. It separates what must be done within the month — often inexpensive and highly protective — from what belongs in a multi-year plan. That second set is the raw material of an IT master plan.
The remaining question is who will implement these decisions. A small business with no IT leadership can entrust that steering to a part-time CIO; without someone to carry the list, the best audit ends up in a drawer. That is why, at Maeliom Consulting, an audit ends with a presentation and a decision on next steps — not with a file being sent.
Common questions
How long does an IT audit for a small business take?
It depends on the question asked, the size of the system and how readily documents are available. Scoping sets a realistic duration before starting, and that is one of its purposes.
What is the difference between an IT audit and a security audit?
An IT audit covers the whole information system, security included, to inform management decisions. A security audit goes deeper into security alone, often with technical testing.
Can our IT supplier carry out the audit?
It knows the system, but it would then be auditing its own work and could sell the fixes. A view independent of operations gives conclusions that are easier to defend.