Most outages that hurt aren’t caused by missing technology. They’re caused by missing documentation. A server dies at 2 a.m. and the on-call engineer has never seen the system before. An auditor asks for evidence that patches ship inside the remediation window; you have no record. Someone leaves and six months of tribal knowledge walks with them.

Every one of those failures was on your risk register — you just never wrote it down.

The four things documentation actually buys you

Not “peace of mind” or “professionalism”. Concrete outcomes an operator can point at.

  1. Consistency. The same task produces the same outcome regardless of who runs it or when. Variation is where incidents begin — different sysadmins remember slightly different flag defaults, and the third one to touch the box breaks something the first two didn’t.
  2. Auditability. Every NIS2 and ISO 27001 audit finding I’ve seen documented in public post-mortems shares one root cause: no evidence trail. The control might exist in practice. The audit fails because nobody can prove it.
  3. Speed under pressure. During an incident, an SOP takes decisions off the operator. They execute. They don’t invent. Mean-time-to-recover drops when the on-call engineer isn’t also the process designer.
  4. Institutional memory. People leave. Contractors get rotated off. The knowledge belongs to the organisation only if it’s written down.

What “undocumented” actually looks like

Rarely a full absence. Usually one of these:

  • A README from three years ago that describes a hostname that no longer exists, referring to a package version two majors behind, with a warning at the top saying “TODO: rewrite this”.
  • A confluence page last edited by someone who left in 2024, marked “draft”, with three comments from different people asking whether it’s still current.
  • The senior sysadmin’s memory. Reliable until they’re on holiday. A month later still reliable, until they’re on holiday during an incident.
  • A Slack thread from June 2025 where someone worked out the correct procedure in real time. Now buried under 40,000 subsequent messages and impossible to find.

Every one of those reads as “no procedure exists” to an auditor.

The compliance framing

Documentation isn’t a bureaucratic accessory to a control — it is the control, or it’s how you evidence the control. Two examples from standards this site references often:

  • ISO 27001:2022 A.5.37 — Documented operating procedures. If the procedure exists and works but isn’t documented, the control is ineffective from an audit standpoint.
  • NIS2 Article 21(2)(a) — Policies on risk analysis and information system security. “Policies” here means written, approved, dated, reviewed. A whiteboard doesn’t qualify.

The pattern repeats across GDPR (Article 30 records of processing), PCI-DSS (documented policies for every requirement), and ISO 9001 (documented information for processes affecting output quality). Different acronyms, same expectation: if it isn’t written down, it isn’t happening.

What good looks like — briefly

The rest of this mini-series unpacks the how. In one sentence per article:

  • Week 2 — Get the document type right (policy vs standard vs SOP vs work instruction) before you start writing anything.
  • Week 3 — Five writing rules that separate an SOP an on-call engineer follows from one they ignore.
  • Week 4 — The eight-section SOP structure auditors expect, with each section explained.
  • Week 5 — A complete, production-ready SOP for SSH key rotation you can fork tomorrow.

Start here — one action this week

Pick one task your team performs at least monthly that isn’t documented today. Not the whole risk register. One task.

Ubuntu security patching. Cloudflare API-token rotation. Nightly backup verification. Whatever comes to mind first — that’s the one that needs it most.

That’s the SOP you write next week, using the structure from Weeks 2–4.

Further reading

  • ISO/IEC 27001:2022, Annex A.5.37 — Documented operating procedures.
  • NIS2 Directive (2022/2555), Article 21 — Cybersecurity risk-management measures.
  • ISO 9001:2015 §7.5 — Documented information.