In most Polish SMEs the knowledge of how IT actually works sits in a single head. When that head leaves the building, what's left is an empty desk, a handful of admin logins, and the question of why nobody at 11pm knows where the backups are. IT documentation is the boring thing nobody writes. That's exactly why it's one of the cheapest ways to reduce risk in your company.
In one project we rebuilt the documentation for a 25-person packaging printer whose IT person handed in a two-week notice. He left behind a OneNote folder of passwords, a heavily outdated Visio diagram, and himself as the sole administrator in 11 SaaS panels. The reconstruction took us six weeks and cost the company more than a year of that person's salary. Not because the IT guy was malicious — quite the opposite, he helped after hours as much as he could. Because the knowledge had never been written down, since "he just knew it".
That's the real cost of missing documentation. Not hypothetical, not from some Gartner report — from a six-week invoice for figuring out who runs what, where.
Why nobody writes it
IT documentation in SMEs doesn't exist because it always loses to whatever's urgent. The IT person puts out a fire, closes a ticket, goes back to the queue. Writing down what they just did would take another 20 minutes they don't have. After two years of that logic, almost nothing in the company exists outside one person's memory.
The second reason is more human. Written-down knowledge weakens your bargaining position. Few IT people will admit it out loud, but being irreplaceable is a strategy for some. It's not bad faith — it's that nobody rewards documentation, and everybody rewards "saving the day". If the owner of the company wants things written down, they need to require it, not hope it will happen by itself.
The third reason: no format. Most attempts end up as an 80-page Word doc that's out of date after a year and that nobody opens. Format matters — more on that in a moment.
What actually has to be written down
Complete IT documentation is an unreachable ideal. But there's a minimum without which the company loses control the moment the IT person walks out. That minimum fits on 10 to 15 pages and covers four areas.
- Accounts and access. A list of every admin account (Microsoft 365, ERP, hosting, domain, antivirus, backup), where MFA is enabled, who is the "reset of last resort", and what happens when the main account gets locked.
- Topology and hardware. What physically sits in your server room or rack, how it's connected, where the routers, switches, NAS boxes live, on which contracts and with what warranty end dates. A one-page Draw.io diagram is enough.
- Incident playbooks. What to do when the internet goes down, when the file server stops responding, when data gets encrypted, when the owner's mailbox disappears. Three steps per scenario. Not full instructions — anchor points: who to call, where to look, what not to touch.
- Contracts and licenses. Who supplies what, on what terms, until when. Not copies of the contracts (those live with accounting), just a one-page table: vendor, system, monthly cost, renewal date, contact person.
That's it. Everything else is a nice extra. These four areas keep the company running until a successor or external provider takes over.
A format that has a chance of surviving
The worst documentation is the Word doc on the IT person's laptop. The second worst is the SharePoint nobody knows how to search. The best is the one short enough to skim in 15 minutes and easy enough to edit in 2.
Three formats tend to work in practice. Notion or Confluence for companies already licensed for something similar. A password manager (Bitwarden, 1Password) with extended notes on every entry — for small teams where it all boils down to access anyway. Simplest of all: one Markdown file in a Git repo, accessible to the company owner and the IT person. Sounds technical, but works surprisingly well — Git shows the change history, so you know who added what and when.
What we don't recommend: documentation in email, as Teams attachments, in a forgotten OneNote, or in a PDF nobody edits because it's a PDF. The format has to allow quick edits, otherwise within three months it starts lying to you.
How to start in a single day
Full documentation takes weeks, but the skeleton can stand up in a single working day. You don't wait for "a calmer week" — that week is not coming.
- Block a whole day with your IT person — not half, not an hour, a whole day.
- Start with the list of admin accounts. Every account, every system, every panel. Enable MFA wherever it's missing. Write down who is the "emergency account" for each critical system.
- Sketch a one-page topology diagram. Not perfect, just readable. Routers, switches, server, NAS, network printers, who-talks-to-whom via cable.
- Write 5 incident playbooks, three steps each. Internet down, file server unresponsive, ransomware, main account locked, office phones dead.
- Put every contract into a table. Vendor, system, cost, renewal date. Renewal dates are the most commonly forgotten trap.
By end of day you have 8 to 12 pages the owner understands and can hand off if needed. This is not "documentation worthy of an award" — this is documentation that saves your skin.
When it turns out to have been worth it
Documentation doesn't pay off when everything works. It pays off once, hard, at one of three moments. First: your IT person hands in notice with two weeks to go. Second: a security incident hits and you urgently need to know who has access to what. Third: you switch IT providers and the new one wants to start from something other than a six-week discovery phase.
In that same packaging printer a year later, ransomware hit one of the two servers. The documentation we'd written up earlier let us restore services in 11 hours, because everyone knew where the backups were, what the hypervisor passwords were, and who to call at the ERP vendor. Without that documentation it would have been 3 to 5 days. The difference between 11 hours and 3 days in a manufacturing company is roughly the entire monthly margin.
IT documentation is boring, undervalued and absolutely critical. If it doesn't exist in your company, this weekend is a good moment to start — or to ask someone who does this for a living. The first conversation costs nothing.
Missing IT documentation doesn't hurt — until it does. And then it hurts everywhere at once.