IT documentation best practices small business advice keeps missing
The wiki has ninety-one pages. Fourteen were written in a burst two years ago and describe a system that has since been replaced. The most recently edited page is the one you updated last week, and you are also the only person who has opened any of them this quarter.
Meanwhile three specific pages get read constantly, mostly by you, mostly at speed, and two of them are not in the wiki at all.
What it documentation best practices small business guidance gets wrong
The standard advice is to document comprehensively. Cover everything, keep it current, structure it well. That advice is not incorrect so much as unachievable by one person, and the failure is not partial: a wiki that is 40 percent current is worse than one that is obviously incomplete, because a reader cannot tell which 40 percent.
The alternative is not to document less. It is to be honest that documentation serves two entirely different purposes, which pull in opposite directions.
Documentation people use is short, findable under stress, and tells you what to do. Its enemy is length.
Documentation that satisfies a requirement is complete, approved, versioned and reviewed. Its enemy is drift.
Trying to make one artefact do both produces a document that is too long to follow and too informal to audit. Separating them is the whole technique, and it is the same policy-plus-procedure split as the ISO 27001 policies note.
The three pages that get read
Consistently, across every small company I have worked in.
How to get emergency access. Where the break-glass credentials are, how to retrieve them, and what to do afterwards. Read exactly when something is badly wrong, so it has to be findable when the usual systems are not available. That constraint rules out putting it in the wiki that requires the identity provider you cannot reach, which is the circular dependency people build without noticing.
The leaver checklist. Read every time somebody leaves, by whoever is available, under time pressure, with a compliance consequence for getting it wrong. This one should be a script rather than a page, per the offboarding note, and the page is then about how to run the script and what to check.
Who to call. Which supplier, which support contract, which account number, which escalation path. Nobody memorises this and everybody needs it at the worst moment. It is the single highest-value page in most companies and it is usually stale, because supplier contacts change and nothing prompts a review.
Get those three genuinely right and you have covered most of the actual reading. Everything else is reference material consulted occasionally, which is a lower bar.
What makes a page usable under stress
Different properties from what makes a page complete.
Findable without search. If retrieving it depends on remembering a title or on a working search index, it fails at the moment it matters. Three pinned links, or a printed card in a drawer for the emergency one.
Answers "what do I do" in the first screen. Context and rationale below the steps, not above. Somebody reading this is not curious, they are stuck.
States its own freshness. A date and an owner at the top. A reader can then weigh it. An undated page is either current or two years stale and there is no way to tell.
Names systems as they appear on screen. Not "the identity platform". The actual name in the actual portal, because the reader is looking at the portal.
Says what success looks like. "You will see the account status change to Disabled." Otherwise somebody stops halfway and cannot tell whether it worked.
Where the ISO 27001 requirement diverges
Clause 7.5 covers documented information: it has to be identified, in a suitable format, reviewed and approved, available where needed, and protected. Annex A adds specific documents.
That overlaps with usefulness in one place and diverges in two.
The overlap. Both want a named owner and a review date. Do that once and it serves both.
The divergence on length. The standard does not ask for long documents, but audit anxiety produces them, and a forty-page procedure is unusable. Keep the procedure short and let the evidence do the proving.
The divergence on audience. A leaver script's output is better audit evidence than any document, because it shows the process ran rather than asserting that it exists. So the thing satisfying the requirement is a report, not a page, and scheduled evidence covers more of clause 7.5 than a wiki ever will.
The runbook that is worth writing properly
Beyond the three, there is one category worth real effort: whatever you would have to do during an incident.
The NCSC's incident management guidance is a reasonable structure to borrow, and the part that matters for a small company is having decided in advance who declares an incident, who talks to customers, and who can authorise spending. Those three decisions are slow to make under pressure and fast to write down beforehand.
What makes an incident runbook different from other documentation is that it will be read by somebody stressed, possibly not you, possibly at three in the morning, and possibly on a phone. So it is a sequence of decisions with names against them rather than a description of systems. The systems are documented elsewhere; the runbook is about who does what and in what order.
This is also the document a tabletop exercise tests, and the most common finding from a first exercise is that nobody could find it. That is a documentation finding rather than a process one, and it is fixed by pinning a link rather than by writing more.
What to do with the ninety-one pages
Not a rewrite, which will not finish.
Mark them. A one-line banner at the top of each: current, unverified, or superseded. That takes an afternoon for ninety-one pages because you are not reading them properly, only classifying them, and it makes the whole wiki usable immediately, because a reader can now tell which pages to trust.
Then delete the superseded ones rather than archiving them. An archived page still appears in search results, which is the entire problem.
The remaining unverified ones get promoted to current when somebody next uses them and finds them correct. That distributes the verification across the year and attaches it to actual use, which is the only mechanism that survives.
The honest test
For each page, ask when it was last read by somebody other than its author. If the answer is never, it is not documentation, it is notes, and that is fine as long as nobody is relying on it.
Then ask the harder version: if you were unavailable for two weeks, which three pages would somebody need. Write those properly. That is the whole job, and it is also the only mitigation available for the key person risk that belongs honestly in your risk register.