Every business’s IT runs on a body of knowledge — how the network is laid out, where the credentials live, which vendor holds what, why that one strange setting exists. The only question is where that knowledge lives: written down and owned by the business, or resident in someone’s head — an employee’s, a technician’s, a provider’s. The second arrangement works fine right up until the head is unavailable, departed, or on the other side of a dispute — at which point the business discovers it has been borrowing its own institutional knowledge. Documentation is the fix, and it’s less a writing project than an ownership principle with a maintenance habit attached.
What complete documentation contains
Six registers, most of which this library has been building all along: the asset inventory — hardware, ages, warranties · the network map — how the zones connect, addressing, what the firewall’s rules mean · credentials, in a manager — every system’s admin access, break-glass arrangements included, never in a spreadsheet named “Logins - FINAL” · the vendor and service register — every provider, account numbers, support lines, renewal dates, and who owns the domain · the how-and-why notes — configurations explained, changes logged, the strange setting’s reason recorded, because undocumented decisions become unremovable mysteries · and the response documents — the IR plan, the runbook, the policies. None of it is literature; all of it is the difference between every future problem starting from knowledge versus starting from archaeology.
The ownership principle (the part that’s non-negotiable)
Whoever writes the documentation, the business owns it — accessible on demand, exportable in full, survivable across any relationship’s end. This is the principle to establish explicitly with any IT provider, and it’s a clean character test: professional providers document in proper platforms and treat client access as obvious (it’s how we work, because documentation held hostage isn’t a service — it’s leverage); a provider who treats your environment’s documentation as their proprietary asset has told you exactly how an exit would go. The same principle applies internally: the heroic IT person whose knowledge lives nowhere else isn’t job security — it’s key-person risk with a salary, and documenting it protects them (vacations become possible) as much as the business.
The staleness problem, and the habits that solve it
Documentation’s failure mode isn’t absence — it’s decay: the network map describing 2022, the credential list missing the last three systems, trusted precisely because it’s written down. Wrong documentation misleads with authority, which can be worse than none. The counterforces are habits, not heroics: documentation updates ride the change — the one-line change log, the new system’s entry created at deployment, the departure’s cleanup on the offboarding checklist — because “we’ll document it later” is where staleness is born · an annual reconciliation pass alongside the IT plan: each register walked against reality, an hour that keeps the whole body honest · and usage as the test — documentation that’s actually consulted (by the new technician, during the restore test that follows the runbook literally) self-corrects; documentation nobody reads rots silently, which is an argument for building the reading into the drills.
The payoff, everywhere at once
Owned, current documentation is the quiet multiplier under everything: support gets faster (every ticket starts from the map instead of discovery) · incidents get answered instead of excavated · provider transitions become handovers instead of hostage negotiations · audits and insurance applications become lookups · and a sale or acquisition finds its diligence pre-assembled. It’s clerical work with compound interest — the same family as the inventory it contains.
The bottom line
IT documentation is institutional knowledge converted from borrowed to owned: six registers, kept in real platforms, updated as part of every change, reconciled annually, and — above all — belonging to the business, exportable on demand, whoever maintains it. Establish the ownership principle out loud, build the update habits into the processes that already run, and the day a key head is unavailable — every business meets that day — the knowledge stays home.