What a small company should have documented in its IT
It is enough if an authorised person can learn from the documentation what the company uses, who owns it, where access is securely stored and what to do in an outage or a handover.
Rather talk it through?
Describe the situation and I will suggest a first step and an estimate of the scope.
Let’s talkThe documentation minimum for a small company
Start with information whose loss would bring operations to a halt or make a handover impossible. Detail can be added gradually, according to how critical each part is. For every item, record the owner, the person responsible and the date it was last verified.
Devices and software
Computers, servers, NAS, network devices, printers, serial numbers, warranties, operating systems, key applications and licences.
Accounts and services
Domains, DNS, email, cloud, hosting, the registrar, the billing account, administrators and the emergency recovery method.
Network and dependencies
Internet connections, IP addressing, Wi‑Fi, VPN, branch offices, public-facing services and a brief diagram of what depends on what.
Backup and recovery
What is backed up, where to and for how long, who receives error reports, where the keys are and when the last restore test took place.
Suppliers and contracts
Contact persons, customer numbers, scope of support, response terms, notice periods and licence renewal dates.
Operating procedures
Where to report an incident, who can approve downtime, what to do when an employee joins or leaves, and recovery priorities.
Documenting passwords does not mean a spreadsheet of passwords
The description of the environment can live in an internal wiki or a shared document, but secrets belong in a password manager with controlled permissions and an access history. The documentation only needs to say where access is stored, who can release it and how emergency recovery works.
- every administrator uses their own named account
- a shared password exists only where separate accounts cannot be created
- the second factor is not tied solely to one supplier’s private device
- emergency codes are kept separate from everyday working access
- removing access is part of every employee or supplier departure
- the domain and the main cloud account are demonstrably under the company’s control
An authorised representative of the company must know how to gain control. That does not mean every employee should see every password.
How to keep documentation up to date
The most common problem is not that documentation was never written, but that six months later it describes how things used to be. Updating it must therefore be part of the work itself, not a separate task for “some time later”.
- Appoint a documentation owner.Someone is responsible for the structure and regular reviews, even if different people fill in individual parts.
- A change ends with a write-up.A new service, device, VPN or administrator is not finished until the access details, the diagram and the contacts have been updated.
- Add the date of verification.It is more useful to know that someone verified a detail a month ago than to guess the age of a seemingly accurate document.
- Regularly simulate someone’s absence.Can a deputy find the contact, the access and the recovery procedure without phoning someone who is on holiday?
- Archive; don’t delete history without thinking.For changes with a real impact, it helps to know what was in place before and why the configuration changed.
Quick check: can the company handle these five situations?
- regain control of the domain and main email without the current administrator
- find the device that runs the most important business application
- find out when critical data was last successfully restored
- contact the right supplier and prove the customer relationship
- securely remove access for someone who is just leaving
If any of the answers is missing, don’t try to create everything at once. Start with the domain, the main identity, backups and the systems the company cannot work without. When changing supplier, follow the related guide on how to take over IT from a previous administrator. You will find more practical topics in the IT guides.
Let’s start with a risk-based minimum.
An inventory and basic documentation can be the first output of a takeover or a technical audit. Further detail is added where it has practical operational value.