IT that only works while the person who knows is around
In many SMEs, IT holds together thanks to one person: the in-house systems administrator, the consultant who has looked after the company for fifteen years, sometimes the owner, who configured the firewall years ago and has been the only one who knows how ever since. As long as that person is around, everything seems in order.
Then they go on holiday, fall ill or leave. On Monday morning the ERP will not start, and nobody knows where the administrator passwords are, how to restart the service, which number to call about the internet line or which customer code to quote. The fault may well be trivial; the outage lasts hours because what is missing is the information, not the expertise.
This is what IT documentation is for: making sure that the way the systems work does not depend on one person's memory.
What really needs documenting
You do not need to describe everything: you need whatever would let someone competent, but new to your systems, step in during an emergency.
| What | Why it matters | Where to keep it |
|---|---|---|
| Hardware, software and licence inventory, with expiry dates | Knowing what you have and what is expiring, and renewing in good time rather than in a hurry | A single register, updated with every purchase and disposal |
| Network diagram | Addresses, devices, links between sites: without a diagram every network fault means starting from scratch | With the date of the last review |
| Credentials | Getting into the systems when the person who knows the passwords is not there | In a digital vault with named individual access, never in a Word or Excel file |
| Operating procedures (runbooks) | Restarting a service, restoring from backup, what to do if the line goes down: steps someone else can carry out | Short pages, accessible even if the main server is down |
| Contracts, suppliers and support contacts | Who to call, with which customer code, what the contract covers | A single list, with numbers, codes and expiry dates |
| Configurations and change log | Knowing what changed, when and why, if something stops working | A log with the date, author and reason for every change |
| Dependencies between systems | Knowing that the ERP will not start without the licence server, or which machine the warehouse printer gets its labels from | One page for each critical system, linked to the inventory |
On credentials, the rule is simple: a "password.xlsx" file in the shared folder is a gift to anyone who manages to get into the network. We explain how to set up a business password manager in the guide on business passwords. And if your company falls under NIS2, the inventory is not optional: asset management is among the security measures listed in Article 21 of Directive (EU) 2022/2555.
The documentation belongs to the company, not the supplier
The documentation often exists, but it sits on the consultant's laptop or in the supplier's ticketing system: the day the relationship ends, it goes with them. Ask for it to be handed over in a readable format, in a space you control, and write this into the contract. It is one of the points to check before you outsource IT or change supplier.
When we take over an infrastructure, the documentation we produce stays with the company. One of the most common cases we see is an in-house systems administrator who is about to leave: the notice period is the right time to put what they know in writing, and to have someone else try out the procedures while the administrator can still correct them.
How to keep documentation alive
- A named owner: not "IT" in general, but one person who is accountable for keeping it up to date, even when others do the writing.
- It is updated with every change, not once a year: a change is not finished until it is written down. A new firewall, a changed rule, a change of supplier.
- Short pages instead of a manual: one page per system, one per procedure. Nobody opens a three-hundred-page manual, and it all goes out of date at once.
- It is tested: someone other than the author of the procedure tries to follow it, for example during a restore test. Wherever they get stuck, the procedure needs correcting.
- It is reviewed on fixed dates: contacts and contracts at every renewal, emergency procedures at every test of the business continuity and disaster recovery plan.
The most common mistakes
- Documentation in the supplier's head. If it exists only in their files, changing supplier means starting from scratch.
- Written once and never touched again. An out-of-date document wastes time just when you need it: it points to devices that no longer exist and procedures that no longer work.
- Credentials in plain text in the network diagram, in emails, on the note stuck to the monitor.
- Writing for people who already know. "Restart the service as usual" is no help to someone who does not know what the usual way is.
Quick checklist
- I know where the hardware, software and licence inventory is, and when it was last updated;
- administrator credentials are in a digital vault, accessible to at least two people;
- there is an up-to-date network diagram, including the links between sites;
- every critical system has a written restore procedure, accessible even when the systems are down;
- someone other than the author has followed at least one procedure in the last twelve months;
- supplier documentation has been handed over to the company, in a space the company controls.
In short
If IT only works as long as a particular person is there, the company carries a risk that does not appear on any balance sheet. A few things, written well, are all it takes: inventory, network, credentials in a digital vault, restore procedures, contacts and changes. The documentation belongs to the company, has an owner, is updated with every change and is tested by having someone else follow it.