SOP process documentation

Purpose

Turn scattered descriptions of one recurring process into a usable SOP that states who does what, with which input, under which rule, and what evidence proves completion. The document is specific enough to train a new operator and to expose unresolved control decisions.

Scope

Cover trigger, start and end boundaries, roles, inputs, systems or records, ordered activities, decision criteria, handoffs, controls, exceptions, escalation, service levels, evidence, output records, and review ownership. Model the process named by the run, not an abstract business process. Excluded: executing the workflow, assigning people outside documented roles, changing policy, or approving an exception.

Data basis

• Existing work instructions, policy documents, process maps, tickets, forms, checklists, and sample completed records.
• Role matrix, system glossary, field definitions, service-level rules, control catalogue, and escalation policy.
• Prior SOP or audit findings when the page is a revision.
• Optional process_name and audience inputs.

Result

Produce an SOP document with purpose, scope, definitions, role matrix, prerequisites, numbered procedure, decision table, exception paths, controls, evidence requirements, outputs, measures, and revision metadata. Include a control-and-evidence sheet with activity, risk, control, owner, record, frequency, and source citation.

Quality criteria

• Each procedure step has one accountable role, an observable input, an action, and an output or state change.
• Every branch has a condition, destination, and closure or escalation path.
• Control statements identify what is checked, against which rule, by whom, and what record proves it.
• Sample records are examples, not universal thresholds; all mandatory values come from source policy.
• The documented start-to-end flow has no orphan handoff, undefined term, or unowned exception.

Instructions

Use source policies for normative requirements and observed records for practical sequence. Preserve field names and status values exactly when they are system-facing. Put a decision table beside the step that invokes it. Distinguish “may,” “must,” and “should,” and mark any proposed clarification as a question to the process owner. Do not fill missing SLAs, approval levels, or retention periods with common practice. For a revision, show what changed and cite the prior SOP or finding.

Adapt before use

• Add the governing policy, process map, role matrix, system glossary, and sample records.
• Map accountable roles, statuses, field names, evidence repositories, and escalation paths.
• Define service levels, control frequency, revision convention, and required output measures.