IT documentation: the cheapest insurance you can buy

Every small business has one person who knows how the IT actually works. Where the Wi-Fi password lives, which switch feeds the back office, why you have to reboot the label printer on Mondays. The whole system runs on what is in that person's head. Then that person goes on vacation, or quits, or gets hit with the flu during a server problem, and the company discovers that "Dave knows" was the entire disaster recovery plan.

Documentation fixes this, and it is close to free. A few hours of writing things down buys you faster fixes, cheaper vendor calls, and a business that survives losing any one person.

What to document

You do not need a binder the size of a phone book. You need five things, current and findable.

1. A network map. One page showing how the pieces connect: internet comes in here, hits this firewall, feeds these switches, these access points hang off them, the server and printers live here. Include the make, model, and IP address of each device. A hand-drawn photo of a whiteboard is genuinely fine. When something breaks, this page turns "the internet is down" into "the switch feeding the front office is down," and that difference is hours.

2. Credentials. Every password that matters: firewall admin, router, server, Microsoft 365 or Google Workspace admin, domain registrar, website host, backup system, printer admin pages. The domain registrar login is the one businesses lose most often, and losing it means you can be locked out of your own website and email routing. Credentials do not go in the same document as everything else; more on where they go below.

3. Account and vendor info. Who your ISP is, the account number, the support phone number, the circuit ID if you have one. Same for the phone provider, printer lease, and software vendors. This turns a 40-minute support call into a 15-minute one, because half of every support call is proving who you are.

4. Runbooks. Short, numbered instructions for the things that recur: how to set up a new employee's accounts, how to remove a departing employee's access, how to restart the server safely, what to check when the internet drops, how the Monday label printer ritual actually works. A runbook is not literature. Five to ten numbered steps, written so a smart non-technical person could follow them under stress.

5. The weird stuff. Every network has folklore. The port that is dead, the scanner that only works with one specific driver version, the reason there are two Wi-Fi networks. Undocumented folklore is where new IT people and new employees burn their first month.

Where to keep it

Split it in two.

Passwords go in a password manager. A business password manager, something like 1Password or Bitwarden, with a shared vault for company credentials. Not a spreadsheet named passwords.xlsx, not a Word doc, not a notebook in the top drawer. A password manager encrypts everything, lets you grant and revoke access per person, and shows you who has access to what. Business plans run a few dollars per user per month.

Everything else goes somewhere shared and searchable. A dedicated section in SharePoint, Google Drive, Notion, wherever your company already keeps documents. The requirements are only that it is backed up, that more than one person can reach it, and that it is not on one person's laptop. A folder called "IT" with five well-named documents beats an elaborate wiki nobody maintains.

One copy of the essentials should also survive your systems being down. If the network documentation is only reachable through the network, it is useless on the day you need it most. A printed copy of the network map and vendor contact sheet in a drawer, or a copy in a personal cloud account the owner controls, covers this.

Who gets access

Keep it simple and deliberate:

• The owner has access to everything, including every password, even if they never use it. The business must never be lockable out of its own systems by any employee or any vendor. We put this in writing with every client: you own the credentials, we just use them.
• Whoever does IT work, internal or external, gets the technical documentation and the credentials they need for that work.
• A second trusted person knows where everything is and can get in if the first two are unavailable on the same bad day.
• Regular staff get the runbooks that concern them and nothing else. The office manager needs the new-employee setup runbook, not the firewall password.

And when anyone with access leaves, the passwords they knew get changed. That step is on the offboarding runbook, which you now have.

How to know it is done right

The test is simple to state: if your most knowledgeable IT person disappeared tomorrow, could a competent stranger keep things running using only what is written down? Run a small version of it for real. Pick one runbook and have someone who did not write it follow it, exactly as written, and note every step where they got stuck. Fix those steps. Do that once and your documentation is better than most businesses ever get.

Then put a recurring reminder on the calendar, twice a year, to read through and fix what has drifted. Documentation does not rot loudly. It rots quietly, and you find out during an outage.