Document a repetitive office task in four connected records: the purpose and decision history, the current settings, the operating procedure, and the ownership map. A screenshot-only guide is not enough because it shows what the screen looked like but not why the task exists, who can approve a change, or how to recognize a bad result.
Start with the decision record
State the business outcome in one sentence, such as “send an unpaid-invoice reminder three business days after the due date.” Record the requester, decision owner, date approved, systems involved, data used, recipients affected, and constraints. Add the alternatives considered and the reason this method was chosen. If the task can affect customers, money, access, or records, specify which steps require human approval.
Keep decisions separate from instructions. The decision record explains why the task exists; the runbook explains how to operate it. This distinction helps when the business rule changes but the tool does not, or when the tool is replaced while the rule remains.
Record settings in a readable baseline
Create a compact table with the setting name, current value, purpose, source of truth, owner, last verified date, and whether the value contains a secret. Never paste passwords, private keys, or recovery codes into the document. Instead, name the approved secret-manager entry and who may access it. Include schedules, filters, file locations, notification recipients, retry limits, time zone, and stop conditions.
NIST's configuration-management guidance describes a baseline as a documented set of approved characteristics and treats change control as a process that records, analyzes, tests, approves, implements, and verifies changes. A small office workflow does not require federal paperwork, but the discipline is useful: maintain one approved baseline and make changes traceable.
Assign ownership by decision, operation, and recovery
Name a business owner who decides what the task should accomplish, an operator who monitors ordinary runs, a technical owner who can repair the implementation, and a backup person. One person may fill several roles, but the roles should still be explicit. Record who can pause the task, who approves recipient or payment changes, and who communicates with affected people after an incident.
Add review dates and an escalation threshold, such as three consecutive failures, a material mismatch in totals, a new external recipient, an expired credential, or a tool retiring a required feature. Ownership becomes actionable only when someone knows which event requires attention.
Write the runbook around evidence
For each run, list prerequisites, input location, start method, expected duration, success evidence, output location, and safe stop procedure. Include a sanitized sample of a successful result. Document common failure messages and the first reversible check for each. A useful runbook also says what not to do, such as rerunning a payment export before checking whether the first run completed.
Keep a change log with an identifier, date, requester, old value, new value, risk, test, approval, result, and rollback step. After any change, verify the task with a controlled sample and compare actual output with the expected result.
Review the whole task
Quarterly or after a major change, confirm that the purpose remains valid, owners are available, permissions are appropriate, schedules use the intended time zone, sample outputs are correct, and recovery steps still work. Archive obsolete instructions so operators cannot accidentally follow them. The best documentation is the smallest current record connecting the business decision, approved settings, responsible people, operating evidence, and a tested path back.
Sources
- SP 800-128: Guide for Security-Focused Configuration Management of Information Systems — National Institute of Standards and Technology, Oct. 10, 2019
- Configuration Change — National Institute of Standards and Technology